Shard mining reward only rewarded to first 2/3 submitters

Hi everyone,

This is a point that has come up a bit and I think should be something to discuss.

Currently, as a shard miner I join in the consensus and it looks like I was a productive help to the network but
in the current setup, only the first 2/3 of the miners that successfully submit a signature will be rewarded end of DS round.

This has 2 distinct problems:

  1. Latency becomes a big factor which would to some degree dis-incentivize a healthy widely dispursed decentralized network and would favor nodes to centralize in data centers with super fast connections.
  2. If a miner does not know if his submission was accepted and will generated a reward the miner might loose interest in the network since there is no way to play according, and always being in the late 1/3rd would be a distinct problem that might go back to point 1 and encourage centralization (the need have a fast connection to the current DS lead)

Proposal for Improvement.

  • Reward 20% (just an example suggestion) of the normal reward that a miner would receive if he had been in the first 2/3rd to later submitters up to X seconds after having received the last submission to reach the 2/3rd consensus. Of course, the max time still has to be reasonably short else it might jeopardize the network, but at least it allows for those tight calls when many miners submit valid work but were only milliseconds late due to geographical location etc.
  • Add some way for a miner to query the current DS leader to establish the estimated outstanding balance that will be paid end of DS round.

The problem and the solution that you are describing is somewhat analogous to orphan blocks or stale blocks. Miners producing orphan blocks on some networks (e.g., Bitcoin) are not rewarded, while they do on others (e.g., Ethereum).

The reason why the network only waits for 2/3 of the signatures is for efficiency. The protocol only requires 2/3 of the signatures from the nodes. So, there is a trade-off being made where faster nodes with better connectivity will get rewarded and other remaining nodes won’t be. I am assuming that the network has more than 2/3 of honest nodes and hence less than 1/3 of byzantine nodes and we wish to reward (if possible) all honest nodes.

The improvement proposal does not really solve the problem. It does however increase the number of coinbase rewardees from (2/3\times 600) to (2/3 \times 600) + \epsilon , where \epsilon is some constant 1 \leq \epsilon \leq 200 , and hence is more inclusive, but, it only makes an improvement by \epsilon. It also introduces an artificial delay in inter-block time.

Another proposal would be to reserve a percentage (say 20%) of the reward for all nodes that participated in the network at the PoW level. This would mean that, even if a node’s signature is not counted for at the consensus layer, it can still get some partial reward. This way, miners are incentivized to take part in the network by doing PoW, but if they want to earn more, they will have to come up with better internet connectivity.

NB: 600 comes from the assumption that the consensus group is of the corresponding size.

good points,

But I do not think its a good analogy to compare with orphan blocks, e.g. in an optimal bitcoin network there would be a minimum of orphan blocks, but in Zilliqa’s case no matter how optimal the network is there is still for every block 1/3 will not receive any reward.

I do like your simplified idea of rewarding all participating miners with equal share of the 20%. That puts a floor on the minimum payout just for participation… of course your suggestion of 20% was just an example, but I think its probably a number that is a bit too high. dont want to reward laggards that highly but a floor should exist.

I think the issue is also about security. If we are to offer the remaining 1/3 nodes some reward for just being in the network, will we still able retain the assumption that these 1/3 nodes will not become byzantine?

I think some competition must exist for this assumption to hold, be it CPU/latency in our pBFT consensus or GPU hashrate in Nakamoto consensus. If we do not have competition, it will cause frequent stalls in the Zilliqa network as we have to do View Change to refresh the shard identities.

As for the second request on the API to query outstanding balance, that should be doable. We can start with an issue over at:

of course, I can see the need for the competition to exist and you do not want to end up lots of nodes that do not care about submitting since they will still be rewarded… so that is probably not the way to go either since no incentive apart from showing up…

how about,
Each signing round has a hard minimum time limit? anyone that successfully submitted before the time limits is up goes in a pool, and then as the time limit expires 2/3rd of the total node count are randomly selected, if not enough miners have submitted follow current rules.

this has 2 distinct benefits:

  1. it lowers the arms race that otherwise will arise to optimize to be close to the DS committee members (latency wise)
  2. everyone that does act in the best interest of the network (timely submission of work) has an equal chance to be rewarded.

the difficult part might be how to figure out what the minimum time limit should be, but surely something can be figured out that works.

I created an issue for it, I dont think I will have time to implement in a pull request for a while, too busy with work… but leave it there if anyone want to do it.

I also think the 2/3 will become an issue.

  1. if 1/3 +1 of total node is fast and on USA (as of now) they can do double spending, no need 2/3 of total this is because you only accept first 2/3 only to done consensus so only haft +1 of it can manipulate the network

  2. Latency is become a big problem, while most of DS committee is on the USA as in current testnet, this make nodes outside USA may not profitable even if it node is good spec. From the telegram comunity, a CPU miner with 4 cores CPU in USA is done POW faster than a GPU GTX1070 8GB + 2 cores CPU or a 4 cores CPU miner in South East Asia because of the latency. and a 4 cores CPU miner in USA can get rewards 3-4 fold more than that GPU node in South East Asia.

  3. This 2/3 reward make 1/3 that get less or never get profit will stop joining network in the end and this create vicious circle that number of nodes reduce as time goes because economy reason, (at a DS eposh it will always have 1/3 of nodes get less or never get reward, even if they are fast nodes in epoch 1 they will become “slower” at some point) only DS committee and 2 nodes a shard remain always profitable.

The solution of this and that, imo is not fully race against each node but have a qualify time to submit work like 50% of block time for submitted before the time limit, DS committee should wait to accept more submitting until the time limit then distribute rewards to all node equally

Relating byzantine behavior and competition is probably not right. Competition is a by-product of shared incentives. A node does not turn byzantine (or decides not to do so) because there is a competition. Most generally, a node decides to turn byzantine simply because there is an incentive to do so. The incentive could be monetary or otherwise (e.g., break the liveness gurantees).

As for free riders, it is possible that they may actually be helping in P2P message sharing or gossiping even if they do not actually participate in the consensus layer. So, these free riders may not necessarily be “free riders”.

1 Like

As I mentioned, if the protocol only accept 2/3, if 1/3 is powerful node and malicious, isn’t it mean they can do double spending with only that 1/3 node instead of 2/3?

That is not possible though. There needs to be at least 2/3 signers in a shard for each micro-block to be validated.
What is the assumption here for 1/3 signers being able to double spend?

< 1/3 Byzantine: Network function as per normal.
1/3 \leq Byzantine \leq 2/3 : Network will stall and await View change.
> 2/3 Byzantine: Double spending may occur at microblock level.

I am not sure if I understand your point 1. The underlying security assumption is that not more than 1/3 of the total nodes in a consensus group is malicious. So, if a consensus group is of size 600, then at most 200 of them can be malicious. A transaction is considered valid if it has 400 signatures. Now, your assumption is that 200 of the nodes are in the US and malicious and hence they can provide 200 signatures on a malicious transaction. They still need 200 more signatures on that transaction to be considered valid. This would mean that there should be at least 400 nodes (in total) in the group that are malicious. This violates the initial security assumption. Or am I missing something?

Yes, you understand correctly.
What I question is

  1. if 201 first nodes submit malicious signature, is the network trust this and see other valid 199 nodes as cheating or not? and transactions still valid or not?

  2. if 1 of 400 first nodes submitting invalid signature, is transactions still valid?

It is theory that should work if you accept work of total consensus member, but if you accept only first 2/3, isn’t it mean the sampling size is reduce?

Did you here about Monty Hall problem.
That you can choose a door out of 3 doors, only one door have a car, each others have a goat.
At first the probability to choose the door with car is 1/3.
Then you choose a door and the MC is open a door with a goat and ask you to switch the door or not.
Now people may think the probability is 50/50 but in reality the probability to get a car when change the door is 2/3 instead of 50/50
This is look exactly like the current topic I am talking about.

They need to be valid first before getting accepted as the first 2/3. The sampling size is still the full size.

I am not have deep knowledge in block chain consensus algorithm, please help clarify how they know the signature is valid?
Who is the checker or what machanism?

The mechanism is practical Byzantine Fault tolerance.

The phases are below:

  1. A client sends a request to the leader node to invoke a service operation.
  2. The leader node multicasts the request to the backup nodes.
  3. The nodes execute the request and then send a reply to the client.
  4. The client awaits f + 1 (where f represents the maximum number of nodes that may be faulty) replies from different nodes with the same result. This result is the result of the operation. In this case, it is 2/3 + 1.

The requirements for the nodes are that they are deterministic and start in the same state. The final result is that all honest nodes come to an agreement on the order of the record and they either accept it or reject it.

Thanks for clarifying,
So that mean it wait for the submitted result with is the same signature to reach 2/3 +1 right?

That mean if fisrt 2/3 had devided to have 2 set of signature it will wait for more result from the network and if which one reach the 2/3 +1 fisrt is make that signature valid.

If that the case you are right and my understanding of issue 1 is wrong.

This information help me a lot to understand the machanism of why only 2/3 get rewards.

But still, for some far aways node that have high latency to reach DS committee in US like mine, may not see profit from joining the mining network.

The latency issue still need to discuss for some other solution.

Thanks a lot.

The latency to US will be not too huge of a problem eventually. We are planning to do multi-region AWS deployment at the initial phase. As the network matures, we will should also have more miners from different regions joining the DS committee.

1 Like

That would be great, I am in the process of upgrading my rig to run some efficient nodes for mining zil but this latency advantage make me hard to decide to put more investment.
If you do that, I am easy to upgrading my rig right away lol.