GP006: Desharding and Balancing Miner Rewards

Proposals
1

Summary:

Proposal GP006 aims to address the underutilisation of shards on the network that is currently causing unnecessary resource expenditure and slowing down block production. By temporarily eliminating these shards until the launch of Zilliqa 2.0’s X-Shards, we aim to improve both decentralisation and cost-efficiency on the network, while ensuring that every participant, regardless of their computation power, has a fair opportunity to earn rewards.

Abstract:

We will adjust mining rewards so as to maintain approximately the existing reward structure once we have removed shards, which will have the side effect of significantly reducing the block time; we will take the opportunity to adjust the reward structure to allow miners to run their nodes from more widely distributed locations, allowing for cheaper hosting.

Specification:

The Zilliqa mainnet has traditionally operated with four shards, which has led to underutilisation, slowing down block production and causing unnecessary resource expenditure for both validation and hosting. Therefore, we propose a temporary elimination of these shards until the launch of XShards as part of Zilliqa 2.0.

ZIP-23 presents a comprehensive strategy to not only eliminate the underutilised shards, but also address the existing disparities in miner rewards. The objective is twofold: to harmonise rewards between miners who co-sign proposed blocks rapidly and those who are slower, and to completely remove the current shards until the introduction of X-Shards with Zilliqa 2.0.

The proposal recognises the fact that the discrepancy in rewards is not due to how fast miners solve the PoW puzzle, but rather how swiftly their votes on proposed blocks to the leader of the pBFT consensus are received and is intended to balance this.

The proposed approach will facilitate miners in diversifying the locations of their nodes, moving away from the current core of the Zilliqa network. This, in turn, provides miners with the opportunity to utilise more economical hosting solutions.

We anticipate that the proposed changes will lead to a reduction in rewards for faster miners and an increase for slower ones. Recognising the benefits of efficient mining to the network, our proposal doesn’t aim to completely level the reward discrepancy. Instead, it seeks to reduce the disparity and promote a more equitable reward system while retaining the motivation for high-performance mining.

The proposed approach continues to place value on the contribution of the more efficient miners, whilst providing an avenue for slower miners to earn improved rewards.We believe that this change will not only enhance the decentralisation of the network but will also encourage cost-effective practices by enabling miners to host nodes in diverse locations without compromising their returns.

  • For - implement the proposal
  • Against - keep the reward structure (and block times) as they are.
0 voters
1 Like
2

Just to say that until they are merged, you can find the two new ZIPs - 22 and 23 - in Add ZIP-22 (hybrid consensus) and ZIP-23 (desharding) by rrw-zilliqa · Pull Request #70 · Zilliqa/ZIP · GitHub

1 Like
3
  1. Is Zilliqa going to turn off DS guard nodes as long as shards as well?
  2. Is there any analysis on potential change of the consensus security guarantees?
2 Likes
4
  1. Yes, but not currently before Zilliqa 2 (which doesn’t have the concept) - unless you know of a reason why we should bring this forward?
  2. What analysis we have is in the ZIPs - if you have a particular query, we can address it here? Broadly, this proposal should be security-neutral, and GP-007 should increase security (because the SSNs will now be validating in addition to the miners).
2 Likes
5

@rrw1000

  1. If we call GetMinerInfo on the latest DS Block, we will find out that there are only 180 nodes in the DS committee instead of 600. But in the reality 600 nodes run the consensus. The reason is that 420 nodes are actually guard nodes that are operated by Zilliqa Foundation and because of that not displayed in the API response.
    Currently, out of 2400 nodes, 420 nodes are not rewarded so Miners are left with (1980 / 2400) 82.5% of nodes. While after the upgrade, miners would be able to operate only 180 nodes which is (180 / 600) 30% of nodes. It account to 82.5% / 30% = 2.75x drop in All Miners revenue. Even the proposal states that it compensates miners with increased DS nodes rewards, in the reality it decreases the reward by almost 3 times.
    Please, don’t get me wrong. The idea of getting rid of hundreds thousands dollars spending on Shard Nodes is fascinating. But please, consider decreasing guard nodes number to compensate for the loss or increase the rewards proportionally.

  2. As I mentioned in the next topic, GP-007 is possibly decreasing security because there is no penalty for malicious action(or just inactivity — downtimes are always possible) for staking nodes: GP007: Hybrid Consensus - #7 by vp_ezil

2 Likes
6

As stated in https://github.com/Zilliqa/ZIP/blob/master/zips/zip-23.md#adjusting-mining-rewards, we will increase the DS rewards by 2.78x in order to compensate for the loss you described above. Does this answer your question @vp_ezil?

2 Likes
7

@zf007, no, it does not. 2.78x reward compensates for removing Shard nodes. What I’m talking about is that because 420 — 70% of DS nodes are run by Zilliqa Foundation, miners are left with only 180(30%). So, after the upgrade, each DS round only 30% of Mining Rewards are getting distributed to miners while 70% are not getting distributed at all because guard nodes are not rewarded. Please let me know if you have any questions.

2 Likes
8

We won’t change the total amount of mining rewards: 60% of 204,000 ZIL per DS epoch. This is the amount that is divided by 2400 today and by 600 in the future. Therefore, the 2.78x compensates for the change in how many nodes receive a reward from 1860 / 2400 today to 180 / 600 in the future. It’s a bit more complicated due to the differences between base and cosigner rewards, but these have also been taken into account.

2 Likes
9

Just to reconfirm, as of now 1860/2400 * 204,000 ZIL = 158,100 ZIL is distributed to the miners while after the upgrade it changes to 180 / 600 * 204,000 ZIL = 61,200 ZIL. Am I correct?

If that’s the case, what does hold back Foundation from lowering Guard DS nodes number to at least 210? The mining pools have been operated the nodes flawlessly for many years. I believe that we, as community, are capable of finding a way to make ZIL more decentralized and even more secure by mitigating single counterparty risk.

Why does single counterparty risk is important? Well, each week professional hacker groups such as Lazarus brake into most secure enclaves such as Microsoft[1], blockchain bridges[2] — which cost $2 billion dollars in 2022 solely. The fact, that the whole blockchain is practically in a full control of the single entity makes Zilliqa a tempting target for cyber attacks. In my opinion, such risk holds back the community from bridging value to Zilliqa blockchain.

Why 210 nodes? To confirm a new block consensus requires 401 signatures from 401 nodes while to stop producing malicious block only 201 signatures from nodes are required. As of now, the whole block can be produced only by using guard nodes signatures. I propose to make block production decentralized so to produce block a consensus of many mining pools as well as guard nodes is required, while 201 guard nodes could always stop producing malicious block. I propose to set guard nodes number to 210 keeping 9 nodes as a margin of operation error.

Cutting Zilliqa Foundation Guard Node expenses by 2 times is also a good reason to consider such option. According to my calculations, such move could save at least $300,000 per annum which can be used on other endeavours.

As a final note, I’m a long-term ZIL holder, builder and contributor who supports positive changes that will increase value of the whole blockchain. And I faithfully want Zilliqa to succeed and sincerely like your progress in the past year. There is no offence, I just want to make ZIL a bit better.

[1] Results of Major Technical Investigations for Storm-0558 Key Acquisition | MSRC Blog | Microsoft Security Response Center
[2] https://www.coindesk.com/consensus-magazine/2023/06/02/bridge-exploits-cost-2b-in-2022-heres-how-they-could-have-been-averted/

1 Like
10

I agree with all of your points above and appreciate your input, and I am also a proponent of decentralization. I’ll check with our core team to see if there are any technical concerns against reducing the guard nodes.

2 Likes
11

This proposal has been up for > 3 days, and had 7 votes, all in favour, so I’ve posted an official poll:
https://governance.zilliqa.com/#/gzil/proposal/QmUxaNzKVKjJLBF9RrGvRHvafzS5yFXgafr2ZHcumBUzLh

Please vote!